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REMARKS 

The Office Action and the references cited therein have been carefully considered. 
Claims 1-54 are pending, remain pending in this application and are at issue herein. Claims 
1,13, and 42 have been amended to define claim elements as defined in the application, as 
argued in prior responses, and to place the application in better condition for allowance. 

35 U.S.C § 102 Rejections 

The Examiner has rejected claims 1-8, 10, 12-15, 18, 19, 21, 22, 24-32, 36-39, 42-46, 
and 48-53 under 35 U.S.C. §102(b) as being anticipated by Ludwig et al. (U.S. Patent 
Application No. 6,237,025). The Applicant respectfully traverses this ground of rejection. 
Reconsideration of these rejections in view of the following comments is respectfully solicited. 

It is axiomatic in the patent law that to reject a claim under 35 U.S.C. §102, each and 
every limitation must be found, expressly or inherently, in a single reference and arranged as 
required by the claims such that the reference discloses the identical invention. See MPEP § 
2131. However, Ludwig, et al. '025 does not disclose, explicitly or inherently, the invention 
claimed by claims 1-8, 10, 12-15, 18, 19, 21, 22, 24-32, 36-39, 42-46, and 48-53, and therefore 
cannot anticipate these claims because it fails to teach each and every limitation required 
by these claims as is required by 35 U.S.C. §102 and explained below. 

With respect to claim 1, the Examiner states that column 5, lines 20-27 and column 4, 
lines 57-67 of Ludwig et al. '025 teach a multipoint processing module having at least one 
audio processor module and at least one video processor module and that column 10, lines 
48-60 teach exposing an interface by the multipoint processing module to receive a request 
from an application to command the multipoint processing module to modify its default 
operation to alter at least one attribute. The Examiner further states that Ludwig teaches a 
software for conferencing where the software receives a plurality of multimedia calls and the 
user is able to accept multiple calls at a time and therefore Ludwig et al. '025 meets the scope 
of the claimed limitation "multipoint processing module." The Examiner also states that 
Ludwig et al. '025 teaches at column 14 that a user can cut and paste a region of the received 
video screen and therefore Ludwig et al. f 025 meets the scope of the claimed limitation 
"modify an attribute to change the default operation of the component." 

As the present application states, multipoint processing modules, referred to as 
multipoint processing terminals (MPTs), provide mixing, switching, and other processing of 
media streams. MPTs transcode data between formats and apply signal processing operations 
to the data in its native format without restraining the resources of the host application. 
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Application Programming Interfaces (API's) defined for the MPT provide the application 
using the MPT the capability to change the default behavior of the MPT by allowing the 
application to control the routing audio and video streams in the MPT and control the media 
formats in a multipoint conference. The interfaces include an audio topology control 
interface, a video topology control interface, and a format control interface. The audio 
topology interface allows an application to control the routing of audio streams towards audio 
output streams and configure other attributes such as silence detection, silence compression, 
gain control, and the like. The video topology interface allows an application to control the 
routing of video streams towards video output streams based on the content of the associated 
audio input streams and configure other attributes such as number of seconds to evaluate 
whether a speaker is continuing to speak, number of seconds during which a new speaker and 
video switching process can not be taken over by a second speaker, interrupt periodicity, and 
the like. 

Ludwig et al. '025 has been reviewed and it is respectfully submitted that column 5, 
lines 20-27 and column 4, lines 57-67 of Ludwig et al. ? 025 do not teach a multipoint 
processing module. Column 5, lines 20-27 of Ludwig et al. '025 teach an architecture that 
employs separate real-time and asynchronous networks for real-time audio/video and non 
real-time audio/video, text, graphics, and the like. Column 4, lines 57-67 of Ludwig et al. 
'025 teach real-time audio and/or video teleconferencing. Column 10, lines 48-60 of Ludwig 
et al. '025 teach that the router/codec bank provides analog-to-digital conversion 
/compression of audio/video signals. The CMW (collaborate multimedia workstation) of . 
Ludwig et al. , 025~performs audio and video mixing and provides an audio processor and a 
video processor. The geographically dispersed multimedia local area networks (MLANs) of 
Ludwig et al. '025 connect CMWs and provide audio/video/data networking for CMWs. 
Ludwig et al. '025 teaches that a MLAN server controls audio/video switching circuitry, 
conference bridges, and a wide area network (WAN) gateway. The MLAN server of Ludwig 
et al. '025 has an audio video manager that controls audio/video switching circuitry that 
allows a user to specify which connections should be switched and manages audio/video 
switching circuitry to route audio and video signals to and from CMWs. Clients 
communicate with the MLAN server using TCP/IP network protocols. No teaching or 
suggestion could be found that the MLAN server of Ludwig et al. exposes an interface to 
allow an application to modify an attribute to change the default operation of the MLAN 
server. 

The Examiner is directed to column 18, line 35 to column 20, line 2 of Ludwig et al. 
'025 where Ludwig et al. *025 teaches the interfaces of the CMW of Ludwig et al. *025. 
Ludwig et al. '025 teaches that the CMW has a collaboration initiator that allows a user to 
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initiate and manage videoconferencing, data conferencing, multimedia mail and other 
collaborative sessions with other users across a network. The interface that the collaboration 
initiator presents to a user allows the user to initiate sessions where participants can be 
selected from a graphical rolodex and a desired session type chosen. A user interface that 
allows a user to initiate sessions and select a desired session type does not disclose or suggest 
exposing an interface to receive a request from an application to modify a default operation to 
alter at least one attribute of an audio processor module or a video processor module. 

No teaching could be found in Ludwig et al. ? 025 to expose an interface by a 
component that provides mixing, switching, and other processing of media streams to allow 
an application to modify an attribute to change the default operation of the component. The 
CMW of Ludwig et al. '025 performs audio and video mixing and provides an audio 
processor and a video processor, but does not perform switching or bridging. Ludwig et al. 
'025 specifically teaches that the MLAN performs switching. It is respectfully submitted that 
Ludwig et al. teaches away from exposing an interface by a component that provides mixing, 
switching, and other processing of media streams to allow an application to modify an 
attribute to change the default operation of the component. Furthermore, if the CMW and 
MLAN of Ludwig et al. '025 were to be combined to produce such a component, the 
modification would change the principle of operation of Ludwig et al. '025 (providing a 
significantly reduced networking cost by using existing hardware wherever possible), which 
is not allowed per MPEP §2143.01. 

Therefore, in view of the foregoing, the Applicant respectfully submits that claim 1 
clearly distinguishes over the Ludwig et al. '025 reference. It is respectfully requested that the 
Examiner remove his § 102(b) rejection of claim 1 as being anticipated by Ludwig et al. '025. 

Claims 2-8, 10, and 12 depend from claim 1 and are believed to be patentable for the 
same reasons set forth above for claim 1. With respect to claims 2-8 and 10, no teaching or 
suggestion could be found in Ludwig et al. '025 of commanding a multipoint processing 
module providing mixing, switching, and other processing of media streams to have an 
interface that exposes the commands claimed in claims 2-8 and 10. Specifically, Ludwig et 
al. '025 does not teach or suggest an audio or video crossbar topology or an audio or video 
format. As explained in the instant application (see Fig. 6-8 and the corresponding text), a 
crossbar consists of cross bar nodes with each node having a value that the multipoint 
processing module uses to understand the overall topology. A zero value indicates an 
unconnected node in one embodiment described in the present application. If two or more 
nodes are connected on a single output line, the input with the highest value supersedes other 
inputs. If the values are the same, the inputs are mixed. 
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With respect to claim 12, no teaching or suggestion of a control flag could be found in 
Ludwig et al. '025. Therefore, it is respectfully requested that the Examiner withdraw the 
rejections of claims 1-8, 10, and 12. 

With respect to claims, 13-15, 18, and 19, the Examiner points to column 10, lines 48- 
60 and states that Ludwig et al. '025 teaches exposing an interface by a media service 
provider component or a multipoint processing module to communicate commands and 
indications between the media service provider component and the multipoint processing 
unit. Column 10, lines 48-60 of Ludwig et al. f 025 teach that the router/codec bank provides 
conventional analog-to-digital conversion and compression of audio/video signals received 
from A/V switching circuitry and transmission and routing of data signals to/from a data 
LAN hub. The Examiner points to column 21, lines 55-64 of Ludwig et al. '025 to state that 
Ludwig et al. '025 teaches an interface between a media service provider and a multipoint 
processing module that has a command to complete updating a video frame and display the 
video frame until commanded to release the video frame. The router/codec directs 
transmissions from an input to an output and compresses and decompresses signals. A 
router/codec bank does not providing mixing of media streams and therefore cannot be a 
multipoint processing module. If it is a media service provider, it must interface with user 
applications. No teaching or suggestion of the router/codec interfacing with a user could be 
found. Furthermore, column 21, lines 55-64 teach a function of a CMW. As taught by 
Ludwig et al. '025, the CMW does not interface with the router/codec. Since the CMW does 
not interface with the router/codec, then the router/codec cannot be either of the media 

service-provider or the multipoint processing module of claim- 13. Modifying Ludwig et al. — 

'025 to interface with the router/codec would change the principle operation of Ludwig et al. 
'025, which as stated above is not allowed per MPEP §2143.01 . Therefore, Ludwig et al. ? 025 
does not teach or suggest one of a media service provider or a multipoint processing module 
having all of the elements of claims 13-15, 18, and 19. Therefore, Ludwig et al. '025 does not 
anticipate or make obvious what is claimed in claims 13-15, 18, and 19. It is therefore 
respectfully requested that the Examiner withdraw the rejection of claims 13-15, 18, and 19. 

With respect to claims 21, 22, 24-32, and 36-39, the Examiner has stated that Ludwig 
et al. ? 025 teaches the hardware of the system receives multimedia signals where the hardware 
performs digital to analog conversion, decompression of received streams and routing of the 
received streams (and again refers to column 10, lines 48-67) and that the hardware 
inherently has a driver or software installed thereon to perform the above mention function. 
The present application defines a multipoint processing accelerator, which is an apparatus 
that provides hardware accelerated implementations of multipoint processing module 
functionality. Additionally, a minidriver is a hardware-specific driver that provides only 
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device- specific controls and it uses a class driver to accomplish most actions through function 
calls. The hardware of Ludwig et al. '025 to which the Examiner refers is a router/codec 
bank. A router/codec bank does not perform multipoint processing module functionality. 
Ludwig et al. '025 has been thoroughly reviewed and no teaching or suggestion could be 
found of a hardware specific driver or of a hardware accelerator. 

With respect to claim 25, column 37 of Ludwig et al. f 025 teaches an Expert deferring 
a telephone call for X minutes, putting a call on hold because an urgent priority request has 
been received and resuming the call. Column 40, lines 49-56 teach an Expert switching from 
one mode to another mode so that the Expert will not be disturbed. A periodicity of an 
interrupt service routine is the recurrence (e.g., cycle time) of the interrupt service routine. 
No teaching or suggestion of a periodicity could be found. The Examiner also points to 
column 32, lines 41-64 and column 16, lines 32-28 of Ludwig et al. '025 and states that this 
shows setting/getting a time to evaluate whether a speaker is continuing to talk. Column 32, 
lines 41-64 of Ludwig et al. '025 teach compression/decompression engines and alternative 
delivery strategies depending on if compression is needed. Column 16, lines 32-38 of 
Ludwig et al. f 025 teach a telephone interface integrated into an add-on box and a hold switch 
and audio mute switch that could be added to the add-on box. Compression/decompression 
of audio/video does not teach or suggest setting/getting a time to evaluate whether a speaker 
is continuing to talk. Nor does a hold switch or audio mute switch teach or suggest 
setting/getting a time to evaluate whether a speaker is continuing to talk. No teaching or 
suggestion could be found of setting/getting a time to evaluate whether a speaker is 

continuing to talk; Furthermore, as previously explained, no teaching or 

found of a video crossbar. Additionally, the Examiner states that Ludwig teaches a method 
where the user can schedule an interrupt to receive a note to switch a conference from 
intercom to telephone. It is respectfully submitted that an interrupt as the Examiner is 
describing is not an interrupt service routine. An interrupt service routine is a software 
routine that is activated to respond to an interrupt. The interrupts the Examiner describes is a 
scheduler that notifies a user when to do something or the user entering information into the 
scheduler. Such a scheduler is not an interrupt service routine. 

With respect to claim 37, the Examiner points to column 32, lines 12-30 of Ludwig et 
al. '025 and states that Ludwig et al. '025 teaches specifying an upper limit in bandwidth 
transmission to a video output pin and supplying the upper limit bandwidth transmission of 
the video output pin to a media service provider. The Examiner further states that Ludwig et 
al. '025 at column 10, lines 37-47 teaches WAN switching multiplexer 44 typically creates 
subchannels whose bandwidth is a multiple of 64 Kbps among the Tl, T3, or ISDN carriers 
and that inverse multiplexers may be required when using 56 Kbps dedicated or switched 
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service from these carriers where the upper limit of bandwidth is the maximum bandwidth of 
the subchannel and therefore Ludwig et al. '025 meets the scope of the claimed limitation 
"specify an upper limit in bandwidth transmission." Column 10, lines 37-47 of Ludwig et al. 
'025 teaches that a WAN multiplexer may create subchannels with bandwidth of the channels 
a multiple of 64 Kbps. It is respectfully submitted that this merely teaches that the bandwidth 
for transfer of files among disks is ultimately limited by the bandwidth of the intra-chassis 
and inter-chassis networking. It does not teach specifying an upper limit in bandwidth 
transmission to a video output pin. Ludwig et al. '025 has been thoroughly reviewed and no 
teaching or suggestion of a video output pin or specifying an upper limit to a video output pin 
could be found. 

With respect to claim 39, column 18, lines 19-33 of Ludwig et al. '025 teach how a 
CMW could be created using an add-on box in conjunction with other components. No 
teaching or suggestion of a video frame's average display time could be found in Ludwig et 
al. '025. 

Therefore, for the reasons set forth above, it is respectfully requested that the 
Examiner withdraw the rejection of claims 21, 22, 24-32, and 36-39. 

With respect to claims 42-46 and 48-53, the Examiner states that column 37, lines 1- 
65 of Ludwig et al. '025 teach creating at least one multicast bridging terminal. As defined in 
the instant specification, a multicast bridging terminal is used to bridge a client using one 
type of control signaling and media streaming to a conference that is using different types of 
control signaling and media streaming. Column 37, lines 1-65 of Ludwig et al. '025 teach an 
expert deferring a telephone call for X minutes, putting a videoconference call on hold 
because an urgent priority request has been received, connecting to the urgent priority 
videoconference call and resuming the first videoconference call after the urgent priority call 
is finished. This teaches switching between videoconference calls. No teaching or 
suggestion could be found of bridging a client using one type of control signaling and media 
streaming to a conference that is using different types of control signaling and media 
streaming as required by claims 42-46 and 48-53. With respect to claim 46, no teaching or 
suggestion of a data format being PCM linear could be found in Ludwig et al. '025. 

With respect to claim 52, no teaching or suggestion of a silence period in the input 
stream could be found or adjusting a clock by the length of time of the silence period. The 
Examiner states that Ludwig teaches muting the input stream until the user resumes the video 
or audio call (and refers to column 29, line 31 to column 30, lines 20) and therefore Ludwig 
et al. '025 meets the scope of the claimed invention. It is respectfully submitted that muting 
an input stream means that the stream has audio data to mute. Otherwise, there would be no 
reason to mute the audio stream. Furthermore, muting an audio stream does not teach or even 
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suggest that there is a silence period in the input stream. Therefore, Ludwig et al. cannot 
teach that there is a silence period in the input stream. 

With respect to claim 53, column 32, line 31 to column 33, line 20 of Ludwig et al. 
f 025 teaches compression and decompression of an audio/video file. There is no teaching or 
suggestion that the size of the data frames of the compressed and decompressed files are of 
different sizes. No teaching or suggestion could be found of transforming data frames of a 
first size into data frames of a second size. The Examiner further states that Ludwig et al. 
'025 teaches compressing data streams and it is well known in the art that compressed data 
streams are of smaller size than the uncompressed data streams. It is respectfully submitted 
that compressing/decompressing data streams does not teach or suggest the steps of calling an 
interface to send input data samples of a first size to a source filter; sending the data in the 
input stream directly down stream if the first size is equal to the size of the output stream 
frame size (the second size), and transforming data samples of the first size into data sample 
of the second size of the first size is not equal to the second size as required by claim 53. 

Therefore, for the reasons set forth above, it is respectfully requested that the 
Examiner withdraw the rejection of claims 42-46 and 48-53. 

35 UXC. §103 Rejections 

To establish a prima facie case of obviousness, there must be some suggestion or 
motivation, either in the references themselves or in the knowledge generally available to one 
skilled in the art, to modify the reference or combine teachings and not based on Applicant's 
disclosure. See M.P.EtP. §2142. Any proposed modification cannot render the prior art 
unsatisfactory for its intended purpose or change the principle of operation of a reference. 
There must be a reasonable expectation of success and the prior art references must teach or 
suggest all of the claim limitations. See M.P.E.P. §2143. Conclusory statements cannot be 
relied on when dealing with particular combinations of prior art and specific claims. The 
rationale for combining references must be put forth. In re Lee, 61 U.S.P.Q.2d 1430, 1433. 
The Examiner can satisfy the burden of showing obviousness of the combination "only by 
showing some objective teaching in the prior art or that knowledge generally available to one 
of ordinary skill in the art would lead that individual to combine the relevant teachings of the 
references." 

The Examiner has rejected claims 9, 1 1, and 23 under 35 U.S.C. §103 as being 
unpatentable over Ludwig et al. '025 in view of Roy (U.S. Patent No. 6,600,725). This 
ground of rejection is respectfully traversed. Reconsideration of these rejections in view of the 
following comments is respectfully solicited. 



22 



In re Appln. of Van Buskirk et al. 
Application No. 09/539,026 

Claims 9 and 1 1 depend from claim 1 and are believed to be patentable for the same 
reasons set forth with respect to claim 1. Claim 23 depends from claim 21 and is believed to 
be patentable for the same reasons set forth above for claim 21 . Furthermore, the Examiner 
states that column 16, lines 32-38 and column 17, lines 36-44 of Ludwig et al. '025 teach 
enabling and disabling automatic gain control. Column 16, lines 32-38 of Ludwig et al. '025 
teach a handset/headset jack, a telephone interface integrated into an add-on box and a hold 
switch and audio mute switch that could be added to the add-on box. Column 17, lines 36-44 
teach that outgoing audio signals pass through standard preamplifier and equalization 
circuitry where the desired signal is selected by standard switch circuitry. The Examiner 
further states that Ludwig et al. '025 at column 17, lines 10-27 uses Add-in box 800 interface 
with standard amplifier and equalization circuitry, as well as an adaptive room echo canceller 
814 to eliminate echo, minimize feedback and provide enhanced audio performance when 
using a separate microphone and speaker and that in particular, use of adaptive room echo 
cancellers provides high-quality audio interactions in wide area conferences. It is 
respectfully submitted that the Examiner is inferring from the adaptive room echo canceller 
that automatic gain control is taught. This inference is respectfully traversed. It is 
respectfully requested that the Examiner put forth adequate evidence as required by MPEP 
§2144.03 to show that column 17, lines 10-27 teaches automatic gain control. No teaching or 
suggestion of automatic gain control could be found in Ludwig et al. '025 or in Roy 725. 
Furthermore, as previously indicated, no teaching or suggestion could be found of specifying 
a periodicity of an interrupt service routine in Ludwig et al. '025 and no teaching or 
suggestion of specifying a periodicity of ah interrupt service routine could be found in Roy 
725. Therefore all of the claim limitations of claim 9 or 23 are not taught or suggested, 
singly or in combination, by Ludwig et al. '025 or Roy 725. 

With respect to claim 1 1, a fast update is used to signal a device to send a new frame 
or group of blocks or macroblocks at the devices earliest convenience to compensate for the 
image quality degradation due to packet loss or when source switching occurs in multipoint 
applications. Column 37, lines 44-54 of Ludwig et al. '025 teach that a user can add 
additional callers to a conference. The Examiner further states that Salesky (U.S. Patent No. 
6,343,313) teaches a method of updating blocks every interval of time by sending the blocks 
that have been changed (and refers to column 12, lines 17-67 of Salesky et al. 313) and 
therefore Salesky et al. '313 meets the scope of the claimed limitation "a command to perform 
a fast update of a macroblock." The Examiner has not rejected claim 1 1 as unpatentable over 
Ludwig et al. '025 in view of Roy 725 and not Salesky et al. 313, so it is respectfully 
requested that this statement be withdrawn. Furthermore, even if claim 1 1 was rejected in 
view of Salesky et al. 313, Salesky et al. 313 at column 12, lines 17-67 teaches that updates 
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for the capture rectangle may be requested by the server, or sent at fixed or variable times 
announced by the present client automatically or as determined by the presenter, or sent at the 
command of the presenter. The blocks sent out by the presenter are just the blocks which 
have changed since the last update. The presenter might also send the entire set of blocks or 
send the blocks as difference (delta) blocks as opposed to the full information base blocks. It 
is respectfully submitted that sending updates for the capture rectangle at the request of the 
server, or sent at fixed or variable times announced by the present client automatically or as 
determined by the presenter, or sent at the command of the presenter does not teach or 
suggest sending a new frame of group of blocks or macroblocks at the device's earliest 
convenience to compensate for the image quality degradation due to packet loss or when 
source switching occurs in multipoint applications. No teaching or suggestion in Ludwig et 
al. '025 or Roy 725 (or Salesky et al. 313), singly or in combination could be found of a fast 
update request. Therefore all of the claim limitations of claim 1 1 are not taught or suggested, 
singly or in combination, by Ludwig et al. '025 or Roy 725 (or Salesky et al. '313). 

Therefore, for the reasons set forth above, it is respectfully requested that the 
Examiner withdraw the rejection of claims 9-1 1 and 23. 

The Examiner has rejected claims 16, 17, and 33-35 under 35 U.S.C. §103 as being 
unpatentable over Ludwig et al. '025 in view of Salesky (U.S. Patent No. 6,343,313). This 
ground of rejection is respectfully traversed. Reconsideration of these rejections in view of the 
following comments is respectfully solicited. 

Claims 16 and 17 depend from claim 13 and are believed to be patentable for the 
same reasons set forth above for claim 13. Claims 33-35~depend from claim-21 and are - — - - 
believed to be patentable for the same reasons set forth above for claim 21 . With respect to 
claims 16 and 33, as previously indicated, a fast update is used to signal a device to send a 
new frame or group of blocks or macroblocks at the device's earliest convenience to 
compensate for the image quality degradation due to packet loss or when source switching 
occurs in multipoint applications. Salesky et al. '313 teaches that updates for a capture 
rectangle may be requested by a server or sent at fixed or variable times announced by a 
presenter client or sent at the command of a presenter. A presenter is the party in a 
conference who is presenting information. Salesky et al. '313 and Ludwig et al. '025 have 
been reviewed and no teaching or suggestion could be found, singly or in combination, of a 
fast update or commands to perform a fast update of a group of blocks or of macroblocks. 

With respect to claims 17 and 34-35, a channel packet rate loss is the rate at which 
packets in a channel are lost. Column 20, line 63 to column 21, line 14 teaches that a filter 
will discard blocks if a client in not able to process each block. The Examiner further states 
that Salesky et al. '313 teaches a method of discarding blocks and displaying a video stream 
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with a loss rate, that there is not limitation on the kind of loss of packets, whether the packet 
loss is due to packets being discarded or other reasons and therefore Salesky et al. 313 meets 
the scope of the claimed limitation "retrieve values of the channel packet loss rate." It is 
respectfully submitted that a discarded packet is not a lost packet. The loss described in 
Salesky et al. '313 is the loss in frame rate, not a loss of packets as required by claim 17 and 
35. No teaching of suggestion could be found in Salesky et al. '313 or Ludwig et al. '025, 
singly or in combination, of a channel packet rate loss. 

Therefore, all of the claim limitations of claims 16, 17 and 33-35 are not taught or 
suggested, singly or in combination, by Ludwig et al. f 025 or Salesky et al. 313. Therefore, 
for the reasons set forth above, it is respectfully requested that the Examiner withdraw the 
rejection of claims 16, 17, and 33-35. 

The Examiner has rejected claims 20, 40, 41, 47, and 54 under 35 U.S.C. §103 as 
being unpatentable over Ludwig et al. '025 in view of Falco (U.S. Patent No. 6,606,1 12). 
This ground of rejection is respectfully traversed. Reconsideration of these rejections in view of 
the following comments is respectfully solicited. 

Claim 20 depends from claim 13 and is believed to be patentable for the same reasons 
set forth above for claim 13. Claims 40 and 41 depend from claim 21 and are believed to be 
patentable for the same reasons set forth above for claim 21 . Claims 47 and 54 depend from 
claim 42 and are believed to be patentable for the same reasons set forth above for claim 42. 
With respect to these claims, the Examiner states that Ludwig et al. '025 does not teach the 
RTP packet limitations and that Falco '1 12 teaches all of the RTP packet claim elements and 
refers to column 3, lines 13-65 of Falco '112. Falco f l 12 has been reviewed and Falco r l 12 
teaches RTP header information. However, no teaching or suggestion of retrieving or setting 
values of a minimum value, a maximum value, a default value and a support value of the 
maximum RTP packet size could be found. The Examiner then states that Ludwig et al. '025 
teaches transferring the stream as a compressed stream and then the receiver would 
uncompress the stream locally (change the size of packets) and then the stream is processed 
at the receiver's processor and refers to column 32 to column 33 of Ludwig et al. '025. The 
Examiner has already stated that Ludwig et al. f 025 does not teach RTP or the RTP packet 
limitations. Therefore, the fact that Ludwig et al. '025 may or may not teach transferring the 
stream as a compressed stream and then the receiver would uncompress the stream locally 
(change the size of packets) and then the stream is processed at the receiver's processor does 
not teach or suggest RTP packets or monitoring RTP packets for a parameter change. No 
teaching or suggestion could be found of monitoring RTP packets for a parameter change. 

Therefore, all of the claim limitations of claims 20, 40, 41, 47, and 54 are not taught 
or suggested, singly or in combination, by Ludwig et al. '025 or Falco '1 12. Therefore, for the 
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reasons set forth above, it is respectfully requested that the Examiner withdraw the rejection 
of claims 20, 40, 41, 47, and 54. 

Conclusion 

The application is considered in good and proper form for allowance, and the 
Examiner is respectfully requested to pass this application to issue. If, in the opinion of the 
Examiner, a telephone conference would expedite the prosecution of the subject application, 
the Examiner is invited to call the undersigned attorney. 



Respectfully submitted, 
evin L. Wingate, Reg. N#738( 



Kevin L. Wingate, Reg. No\ 38662 
LEYDIG, VOIT & MAYER, LTD. 
6815 Weaver Road, Suite 300 
Rockford, Illinois 61114-8018 
(815) 963-7661 (telephone) 
(815) 963-7664 (facsimile) 

Date: June 22, 2004 
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